Sur l'article, WireGuard VPN Walkthrough , Glen a posté la question alléchante:
Comment pourriez-vous vérifier / confirmer que le lien est bien crypté? Si vous utilisez OpenVPN et utilisez Wireshark pour renifler les paquets, vous voyez le protocole OPENVPN répertorié dans le vidage capturé. Existe-t-il un équivalent pour Wireguard?
Pour les tests, voici mes hypothèses:
•.Le serveur Wireguard externe est hébergé à l'adresse IP 100.100.100.100
•.L'interface locale de Wireguard est appelée wg1à 10.192.122.2. Nous n'utiliserons pas wg-quick(voir la solution n ° 2 si vous souhaitez configurer l'interface et suivre)
•.curl --interface eth0 http://httpbin.org/ip donne votre adresse IP externe (90.90.90.90)
•.curl --interface wg1 http://httpbin.org/ip donne une adresse IP vpn (100.100.100.100)
•.Si nous pouvons observer des données non chiffrées lors de l'écoute, eth0la connexion n'est pas sécurisée.
Le HTTP simple n'est pas sécurisé, alors surveillons notre demande à httpbin. Nous pourrons espionner en utilisant
tcpdump -n -v -i eth0 port 80
En exécutant l' eth0instruction curl, nous pourrons voir clairement notre demande et réponse HTTP:
02:58:45.452812 IP (tos 0x0, ttl 64, id 31717, offset 0, flags [DF], proto TCP (6), length 129)
192.168.1.6.40318 > 54.235.130.91.80: Flags [P.], cksum 0x7b68 (incorrect -> 0x26e5), seq 283436622:283436699, ack 1472925892, win 229, options [nop,nop,TS val 323460534 ecr 112785182], length 77: HTTP, length: 77
GET /ip HTTP/1.1
Host: httpbin.org
User-Agent: curl/7.47.0
Accept: */*
02:58:45.504943 IP (tos 0x20, ttl 232, id 59362, offset 0, flags [DF], proto TCP (6), length 372)
54.235.130.91.80 > 192.168.1.6.40318: Flags [P.], cksum 0x675f (correct), seq 1:321, ack 77, win 105, options [nop,nop,TS val 112785194 ecr 323460534], length 320: HTTP, length: 320
HTTP/1.1 200 OK
Connection: keep-alive
Server: gunicorn/19.7.1
Date: Thu, 26 Apr 2018 00:15:35 GMT
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Powered-By: Flask
X-Processed-Time: 0
Content-Length: 33
Via: 1.1 vegur
{
"origin": "90.90.90.90"
}
•.Nous voyons notre eth0adresse (192.168.1.6) parler au serveur httpbin au 54.235.230.91
•.La réponse contient notre adresse IP externe attendue (90.90.90.90)
•.Et oh non, on espionne!
Voyons à quoi ressemblera l'exécution de la wg1boucle:
tcpdump -n -v -i wg1 port 80
tcpdump: listening on wg1, link-type RAW (Raw IP), capture size 262144 bytes
03:10:13.382048 IP (tos 0x0, ttl 64, id 26588, offset 0, flags [DF], proto TCP (6), length 129)
10.192.122.2.42904 > 54.225.185.38.80: Flags [P.], cksum 0x753d (incorrect -> 0x2b18), seq 354179898:354179975, ack 3265920867, win 216, options [nop,nop,TS val 323632516 ecr 2420503305], length 77: HTTP, length: 77
GET /ip HTTP/1.1
Host: httpbin.org
User-Agent: curl/7.47.0
Accept: */*
03:10:13.861353 IP (tos 0x0, ttl 234, id 3103, offset 0, flags [DF], proto TCP (6), length 371)
54.225.185.38.80 > 10.192.122.2.42904: Flags [P.], cksum 0xf0d4 (correct), seq 1:320, ack 77, win 105, options [nop,nop,TS val 2420503425 ecr 323632516], length 319: HTTP, length: 319
HTTP/1.1 200 OK
Connection: keep-alive
Server: gunicorn/19.7.1
Date: Thu, 26 Apr 2018 00:27:03 GMT
Content-Type: application/json
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
X-Powered-By: Flask
X-Processed-Time: 0
Content-Length: 32
Via: 1.1 vegur
{
"origin": "100.100.100.100"
}
•.Nous voyons notre wg1adresse (10.192.122.2) parler au serveur httpbin au 54.235.230.91
•.La réponse contient l' adresse IP externe de notre VPN (100.100.100.100)
•.Et oh non, on espionne! Ou sommes-nous?
Ne vous inquiétez pas, dans cet exemple, nous envoyons du texte en clair à une interface Wireguard et recevons en retour du texte en clair, ce que notre tcpdumpcommande affiche. Cependant, notre interface Wireguard n'a pas réellement la capacité d'envoyer des données réseau n'importe où. Il devra eth0transmettre la charge utile cryptée à notre serveur VPN. Cela signifie que l'écoute eth0mais l'exécution de la wg1boucle affichera le contenu chiffré. Si eth0vous ne pouvez pas lire le contenu, personne d'autre ne le fera non plus.
Nous mettrons à jour notre commande tcpdump car nous ne communiquerons pas TCP sur le port 80. Nous savons que nous communiquerons avec notre serveur VPN, donc capturez uniquement le trafic entre nous et le serveur.
tcpdump -n -X -i eth0 host 100.100.100.100
Comme nous verrons des paquets chiffrés, ils ne seront pas imprimables. Pour afficher le contenu, nous allons voir les données encodées en hexadécimal (qui est l' -Xoption).
J'ai également supprimé l'en-tête IPv4 et l'en-tête UDP, afin que nous puissions nous concentrer uniquement sur les données. Ci-dessous est notre HTTP GETdemande.
0x0000: .... .... .... .... .... .... .... .... ................
0x0010: .... .... .... .... .... .... 0400 0000 ................
0x0020: bef2 24a4 0600 0000 0000 0000 002f b736 ..$........../.6
0x0030: 7448 8e01 778f 7e13 adb8 e66c e307 3d39 tH..w.~....l..=9
0x0040: bfbf f53d a194 211b f0e5 6cab c561 1f5c ...=..!...l..a.\
0x0050: 2c38 906b 1bec 183a 8e41 8bab 3a59 ca0b ,8.k...:.A..:Y..
0x0060: e1ef dda8 e882 4f8a 6590 f517 2d9a 2077 ......O.e...-..w
0x0070: 4830 8673 b26b 1a16 7f3b e358 f3ec b14f H0.s.k...;.X...O
0x0080: 8d97 b15d 9ad3 3962 3e1f 5d6c 96be 0518 ...]..9b>.]l....
Notez que les données commencent par 0400 0000. Si nous croisons cela avec le protocole documenté de Wireguard , nous pouvons confirmer que les données commencent par un 8 bits 4suivi de 24 bits de 0, afin que nous puissions être assurés que nous avons correctement configuré Wireguard. On pourrait creuser un peu plus profondément dans les bits suivants pour capturer la partie index du récepteur du protocole, mais comme heuristique, 0400 0000c'est décent. Gardez à l'esprit que Wireguard n'essaie pas d'obscurcir les données, donc un fournisseur d'accès Internet pourrait raisonnablement essayer de détecter et de bloquer le trafic Wireguard.
Le créateur de Wireguard avait ceci à dire :
WireGuard n'a pas pour objectif d'échapper au DPS [ inspection approfondie des paquets ], malheureusement. Il y a plusieurs choses qui empêchent cela de se produire:
•.Le premier octet, qui est une typevaleur fixe .
•.Le fait que ce mac2soit le plus souvent tous des zéros.
•.La longueur fixe des messages de prise de contact.
•.Clé publique éphémère non chiffrée.
Ainsi, Wireguard n'est pas la panacée pour ceux qui tentent d'échapper aux pare-feu sophistiqués et hostiles (et Wireguard ne s'est jamais présenté comme tel). C'est un excellent VPN qui peut être combiné avec d'autres outils pour répondre aux besoins souhaités.